fix(triggers): route to a window that already exists, and keep a highlight through a rewrite - #28

Two reported defects. They are independent, and each is a single wrong line
in a different file.

1. "Triggers should not be restricted to only be able to go to spawns."

Root cause. Workspace.RouteSpawn (Workspace.cs:172-184 on main) was the
only destination resolver a matched rule had — SharpMUTermApp.OnSpawnLine
(SharpMUTermApp.cs:2905-2931) is its one caller. It computes
SpawnWindowId(sessionKey, target) and, when nothing answers to that id,
registers a brand-new WindowKind.Spawn window. There is no branch in it that
can reach a window that already exists under any other name, so "route this
into the window I already have open" was not a thing a rule could ask for
however it was spelt: a route naming a window on the screen opened a second
one beside it wearing the same label, and the one the user was looking at
stayed empty.

The screen could not express it either. SharpMUTermApp.SpawnTargets()
(SharpMUTermApp.cs:4942-4948) built the F2 route suggestion list out of the
other rules' SpawnTargets and nothing else, so the one place a user reads
what a route may say could name only spawn panes.

One arm of the report was already there and is worth stating precisely: main
in the route list (TriggersScreenRenderer.cs:44-47) is a real choice meaning
SpawnTarget = null, which does reach the main window — but only for a line
the rule does not also gag, because it is not routing rather than routing
there. A gagging rule aimed at the main window deleted the line.

Change. Workspace.RouteLine is the resolver now: a window the target
already names wins, and creating a capture pane is what happens when nothing
does. Workspace.FindRouteTarget is the same lookup with no side effects, so
the shell can still tell "this line opened a pane" from "this line went to one
that was already there" without routing twice.

What a target may reach is deliberately narrower than "any window with that
title", and the scoping is the design rather than caution:

• this session's own windows and the windows nobody owns — always;
• another character's main window — one alt's channel collected into the
  pane you actually read. A main window is admitted across the owner boundary
  because it is a window the user opened by connecting, rather than one a
  capture rule conjured;
• never another session's spawn or auxiliary window. Two characters running
  one capture rule get a pane each, and a bare title lookup would collapse them
  back into one and file the second character's channel under the first — the
  exact defect SpawnWindowId was given an owner to fix. SpawnWindowPerSessionTests
  and TwoCharactersCapturingOneNameStillGetAPaneEach hold both ends of that.
• only a placed window is a destination. Appending to a window no pane holds
  writes into a buffer nothing can draw, which from the reader's side is
  indistinguishable from the rule not firing at all.
• finding never creates. A target is often a template with capture groups in
  it (Channel $1), so the name can be the server's text; the property that
  bounds that is that this arm can only ever land in a window the user already
  has. Making one out of a captured name still goes through RouteSpawn, which
  puts the matching session's own key on it.

Two consequences in the shell. OwnerLabel is stamped on this session's own
capture panes only — it prefixes a tab as Owner: Name, and writing our name
onto a window somebody else owns would rename their pane after whoever last
routed a line into it. And RouteTargets() (the old SpawnTargets()) now
offers the workspace's own windows as well as the other rules' targets, so the
route field can name them; they are suggestions and not the permitted set, so
this widens what is discoverable rather than what is legal.

2. "Highlight colours don't seem to actually work."

Root cause. TriggerEngine.Process (TriggerEngine.cs:256-267 on main)
applied the highlight to the matched region and then, four lines later,
replaced the whole line with StyledLine.FromText(text, TextStyle.Default) —
no colour, no attributes, no left rule. A rule that both rewrote and
highlighted therefore threw its own highlight away on the very next statement.

Highlights work on their own; TriggerEngineTests.Highlight_RecoloursMatchedRegion
has always passed, and an end-to-end check of a highlight-only rule shows the
colour reaching the pane's markup. The combination is what fails, and it is not
an exotic one — it is what a channel rule looks like (route it, tidy it to
» $1, colour it), and it is the shape of this repository's own demo headline
rule (DemoScene.cs:161-174: teal, bold, Rewrite = "» $1"). The F2 screen
badges such a rule H and paints both swatches, so the client promised a
highlight it then discarded, and the only way to find one was to discover that
deleting the rewrite brought it back.

Change. The rewrite runs first, and the highlight then covers the whole of
what it produced. It cannot cover the match's own offsets, because after a
rewrite those address a string that no longer exists; the rewritten text is the
rule's product in its entirety, so colouring all of it is the only reading that
means anything. Without a rewrite nothing moves — the highlight covers the
match and only the match, as it always has, which is the property the
reordering could most easily have broken and is pinned separately.

A later rule's rewrite still replaces an earlier rule's highlighted text, and
that is correct rather than the same bug one rule over: those characters are
gone. Also pinned, so the ordering fix is not later "generalised" into
re-colouring text the first rule never saw.

On the snapshot. --view highlight is the F2 colour-picker screen, not
painted output, so it cannot show this defect — its frame is byte-identical
before and after the fix, which is itself the evidence that the screen was
never where the colour was lost. The defect is in the output path, and it is
proven where the colour actually has to survive: ARewrittenLineReachesThePaneWearingItsHighlight
reads the Spectre markup a pane is fed and asserts #ffd700 is in it.
--view route-edit does move, and correctly: the route field's suggestion list
grows from four entries to five as the workspace's own window joins it.

Tests

Written before the fixes, and each verified to fail on the unfixed behaviour —
3 of the 6 end-to-end tests fail without them (two routing, one highlight); the
other three are regression pins that pass either way by design.

• HighlightRewriteTests (Core) — 7 tests over the rewrite/highlight ordering,
  including the two properties that must not move.
• RouteToExistingWindowTests (Core) — 10 tests over RouteLine, half of them
  about what it must not reach.
• TriggerRouteDestinationTests (Tui) — 6 end-to-end tests over a live
  connection with two characters, asserting the pane the line actually lands in
  and the markup it lands there wearing.

Verification

dotnet build SharpMUTerm.slnx     Build succeeded. 0 Warning(s) 0 Error(s)

Core        total: 900   failed: 0  succeeded: 900
Tui         total: 1607  failed: 0  succeeded: 1607
Graphics    total: 83    failed: 0  succeeded: 83
Scripting   total: 42    failed: 0  succeeded: 42
Web         total: 37    failed: 0  succeeded: 37

🤖 Generated with Claude Code

https://claude.ai/code/session_015nuKnWthnELNkrd86q5KWN

Summary by CodeRabbit

• New Features

  • Trigger-routed lines can now appear in existing matching windows, with new capture windows created only when needed.
  • Routing respects session ownership and preserves existing window labels.
  • Trigger suggestions now include configured destinations and currently available windows.
  • Rewritten trigger text retains highlighting and applies styling across the rewritten line.

• Bug Fixes

  • Improved unread indicators for routed background windows.
  • Closed or inaccessible windows are safely bypassed.

• Tests

  • Added coverage for routing, window isolation, fallback creation, rewriting, and highlighting.